autolink数字技术营销易观数科 | 快速迭代能否真正提升效率？

易观刚开始做方舟这款大数据产品时候，也是在开发交付问题上遇到了比较大的挑战。开发初期新功能需求比较密集，且稳定性不够好，需要频繁给客户升级新功能或是修复bug，团队也是自然而然地运用了敏捷迭代的方法，有问题改问题，有需求做需求。

每次上线都需要实施团队上前方操作，研发人员后方待命，一旦出现问题研发就会直接冲到第一线辅助。这个模式虽然取得了一些不错的成绩，但是伴随着客户数量的增涨各团队已经是不堪重负。

直到公司层面为了更好的服务客户在公司内部提出了“贴身研发”的概念时候暴了雷，“贴身研发”即客户需求至上，快上加快，这样一来需求的数量和随机性都突增。

研发和实施团队由于压力太大，便站出来反对频繁的迭代上线——认为还不如等功能都做好一次交付给客户来的省事，于是和产品团队“吵成”一锅粥，一时间团队几乎到了奔溃边缘。

但这也成为了促使团队深入反思蜕变的转折点。团队一起开会讨论，彻底梳理整个研发模式和交付流程的每一个环节，最终得出的结论是当前交付上线成本过高严重占用了团队的资源。

方舟大平台大数据组件多达10个以上，且多是集群私有化部署，属于重交付运维的产品服务。每一次上线不但要在技术层面去调控更新众多大数据组件，还要和客户做大量的前期沟通，这样交付上线成本必然比较高。

欲练绝世武功，先练心经，心中要有数。为了印证交付上述结论，我们透过问题看本质，用数字来剖析背后隐含的规律。

首先建立工作量估算不完全数学模型：

引入bug 率的概念：

传统模型:

敏捷模型:

将两种模型进行对比：WorkloadA - WorkloadB=  PRNum X PubCost  X UserNum X（g-1）

由此可得出：

第一，传统模式一次上线在bug率比较低的的情况下实际上工作量最小的。说明特定情况下，“敏捷迭代还不如等功能都做完一次上线省事”说法；

第二，团队 bug 率 g 大于1，传统模式的工作量会逐渐大于敏捷模式工作量 。说明传统模式对于bug率比较敏感，bug 率控制的不好的话就是一个无底洞；

第三，交付上线成本 PubCost 是造成敏捷模工作量上升的关键因素。说明敏捷模式相对于传统模式对交付成本比较敏感，客户数越多成本越高。

以上数学模型证实了交付上线成本过高导致总体迭代成本急剧上升的结论，同时易观大数据团队开启了一轮降低交付成本的计划。

易观的做法主要包括以下几点：

在发布方式上：借助易观自研强大的调度器实现版本或补丁发布完全自动化、版本 changelist 生成完全自动化、每日自动发布版本可多达到10个以上；

交付方法上：通过自动化工具的应用实现一键大数据集群部署、一键在线或离线版本升级，最快10分钟内完成从代码提交到交付客户完成；

交付一致性方面：通过对产品的架构改造，并配合版本管理体系的标准化实现增量交付，全量覆盖能够确保交付出去的版本内容完全可控；

沟通方式上：基于以上方式实现结合版本信息管理平台实现最高效的沟通是不言而喻，Only number 便可了如指掌。

经过以上4点变革，易观方舟团队打通了敏捷迭代环节中交付障碍，构建了完整且清晰敏捷闭环，加快了迭代速度的同时却没有较多增加的成本，让团队可以专注在产品研发本身，这成为易观方舟在如此短的时间里能取得喜人成绩背后的力量。

直面自己的问题和敢于变革是易观在20年时代大潮下沉淀下的信经，也希望我们的经历能够鼓励到对数据科学孜孜不倦的你！